-
Notifications
You must be signed in to change notification settings - Fork 123
Handle NIOSSLError.uncleanShutdown correctly #472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle NIOSSLError.uncleanShutdown correctly #472
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome, thank you so much!
// if we have already received the response head, the parser will ensure that we receive | ||
// the complete response. we can ignore this error. we might see a HTTPParserError very | ||
// soon. | ||
if responseHead.headers.contains(name: "content-length") || responseHead.headers.contains(name: "transfer-encoding") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a sufficient check: there are cases where these headers are not present, but we are nonetheless confident of the length of the response. Specifically:
- Responses to a HEAD request
- Responses with a 204 or 304 status code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The HTTPResponseDecoder
will always emit a response .end
after having received a response head, if the request had a HEAD
or CONNECT
method or the response status is 204 or 304.
For this reason, we can expect that we will only be in the streaming state, if we have a "content-length" or "transfer-encoding" header or if the response is EOF terminated. I'm well aware that this is very implicit. If we want to have explicit checks here, I will need to come up with a way to preserve the request method a little longer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, can we get this logic into a comment then? The correctness of this code is not apparent merely from reading it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment added.
|
||
// if we have already received the response head, the parser will ensure that we receive | ||
// the complete response. we can ignore this error. we might see a HTTPParserError very | ||
// soon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment seems to be out of step with the code: it implies that we can ignore the error, but then has logic that sometimes doesn't ignore the error.
36a9c6d
to
5b5931b
Compare
5b5931b
to
3e03472
Compare
Motivation
Fixes #238 and #231.
Changes
HTTPClientTests
into their own fileHTTPClientUncleanSSLConnectionShutdownTests
uncleanShutdown
should be handled automatically (where possible) #238 into the test fileignoreUncleanSSLShutdown
everywhereResult
ignoreUncleanSSLShutdown
onHTTPClient.Configuration
is deprecated and ignored.